NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/408

Internet Message Format | 1996-08-06 | 3.6 KB

Path: solon.com!not-for-mail
From: [e-mail] (Michael J Zehr)
Newsgroups: comp.std.c,comp.lang.c.moderated
Subject: Re: Integral promotion.
Date: 16 Feb 1996 00:10:37 -0600
Organization: Massachusetts Institute of Technology
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <4g174t$[e-mail]>
References: <4fstj7$[e-mail]> <4fvk8c$[e-mail]>
NNTP-Posting-Host: solutions.solon.com

In article <4fvk8c$[e-mail]> Ari Lukumies <[e-mail]> writes:
>Rune Huseby wrote:
>: short test(short x1, short x2);
>: int main(void)
>: {
>:   short result;
>:   result = test(1, 2);
>:   return 0;
>: }

>The numbers 1 and 2 here are by convention considered by compiler to be ints (not
>shorts).

Yes, but because a prototype is in scope for the function "test" they
are converted to the types of the parameters (as if by assignment), so
the compiler converts 1 and 2 to shorts before passing them.

>: short test(short x1, short x2)
>: {
>:   short result;
>:   result = x1 + x2;  /* Warning:  '=' : conversion from 'int '
>:                          to 'short ', possible loss of data */
>:   return result;
>: }
>:
>: My compiler (Microsoft Visual C++ 4.0), automagically converts
>: my short-parameters to int's, even though all variables involved
>: are short. I know that the standard says that all arguments can
>: be converted to the biggest 'type' of all the arguments, but is
>: it correct that char's and short's always are promoted to int's,
>: without regard to the other arguments in the expression?
>
>Chars are converted to ints, because passing a byte (where char equals one byte in
>size) is both inefficient and leads to difficulties in the receiving party (for
>instance, to pass two chars would then pack them into one byte, which the receiver
>would have to be able to handle).


The mechanism of passing and how much space the parameters take up on
the stack (if one exists!) is a complete black box as far as the
standard goes.  It can turn them into hex and engrave the parameter
values on papyrus reeds and have the called function run an OCR to get
the values off for all the standard says.  But if the function
parameter is called a short in the function definition and the program
doesn't violate any constraints (the most likely one to break here would
be a new-style function definition called without a function declaration
in scope) then the parameters are shorts in the function body.  This is
true even on PC compilers that might not be conforming because of other
reasons.

Now what *really* happens here is described in the appendix of K&R2:
A6.1 Integral Promotion:  A character [...] may be used in an expression
wherever an integer may be used. [...] the value is converted to int;

[This article was posted to both comp.std.c and comp.lang.c.moderated.
For the former I ought to be quoting form the standard.  For the latter,
far more people have access to K&R2 to check things than the standard.]

So while

x1 and x2 are shorts and remain shorts regardless of how the compiler
sees fit to pass them to the "test" function, in the expression "x1 +
x2" there values are converted to ints.  Thus the type of "x1 + x2" is
an int and it is *this* that is being converted to a short during the
assignment to result.

The original poster was mostly right in the last sentence -- the values
of short variables in an expression are convert to int if an int can
hold all possible values, otherwise converted to an unsigned int.  It is
neither the arguments nor the parameters that are being converted.

-michael j zehr